代码版本控制到底选择Git还是SVN？

工作几年，项目开发过程中，刚好SVN和Git都用过很长时间。

在对比SVN和Git到底哪个好之前，首先需要解释一个概念：版本控制系统。

这样更加有助于大家对代码版本控制有个全局清晰的认识。

版本控制系统是用来跟踪、制作和管理软件代码变化的工具。它能够帮助开发者存储不同阶段对文件所做的每一个改动，这样我们、或者与我们协作开发的同事就可以在检索到这些改动。

目前主要包含3种类型的版本控制系统：

下面，就分别介绍一下这3种版本控制系统。

本地版本控制系统是位于你本地计算机上的一个本地数据库，其中每个文件的变化都以补丁的形式存储。

每一个补丁集只包含自上一版本以来对该文件所做的修改。

为了看到文件在任何给定时刻的样子，有必要将文件的所有相关补丁按顺序罗列在一起，直到逐个查看找到对应的版本为止。

本地版本控制系统有一个很大的问题，所有东西都储存在本地。如果本地数据库出了什么问题，所有的补丁都会丢失。如果一个版本发生了什么事情，那么这个版本之后的所有修改都会丢失。

另外，与其他开发者或团队合作是非常困难的。

集中的版本控制系统有一个包含所有文件版本的服务器，多个用户可以同时访问服务器上的文件，把它们拉到他们的本地计算机上，或者从他们的本地计算机上把它们推到服务器上。

相对本地版本控制系统，这与其他开发者或团队的合作变得容易。

这种结构的最大问题是，所有东西都存储在集中式服务器上。如果该服务器出了问题，没有人可以保存他们的版本变化，拉动文件或进行协作。

与本地版本控制类似，如果数据库被破坏，而备份没有被保留，你就会失去整个项目的历史，除了人们碰巧在他们的本地机器上有的单一快照。

比较知名的集中式版本控制系统有Microsoft Team Foundation Server （TFS）和SVN。

有了分布式版本控制系统，用户不仅是从服务器上拉取最新的文件快照，而是一种完全镜像存储库，包括全部历史。

因此，在一个项目上合作的每个人都拥有整个项目的本地拷贝，换句话说，拥有自己的本地数据库和自己的完整历史。

在这种模式下，如果服务器变得不可用或出了问题，任何一个用户资源库都可以将项目的版本拷贝发送给其他用户，或者在服务器可用时再推回到服务器上。只要一个用户包含一个正确的副本就足够了。

下面，就分别从服务器架构、分支管理、访问控制、存储要求、可用性等方面对比Git和SVN的差异。

Git 软件被安装在本机上，每个开发者在个人电脑上都有一个项目完整版本历史的拷贝。

Git的各种操作发生在本地，同时充当客户端和服务器，所以，开发人员不必一直处于联机状态。

SVN具有相互独立的服务器和客户端。只有开发者正在处理的文件被保存在本地机器上，而开发者必须处于联机状态，每次操作，用户检出最新文件，然后再将修改提交到服务器上。

SVN 分支是在版本库中以目录形式创建的，这种目录结构是SVN分支的核心痛点。

由于SVN是一种目录，因此，它不能反映出开发者信息，这样，就很容易造成冲突、缺失、杂乱无章等问题。

这使得分支和合并模式变得复杂，这在管理上也很费时。

Git 分支只是对某次提交的引用，它是轻量级的。

你可以在任何时候创建、删除和改变一个分支，而不会影响到提交的内容。

如果你需要测试一个新功能或发现一个错误，你可以建立一个分支，进行修改，将提交推送到中央仓库，然后删除该分支。

默认情况下，Git 假设所有的开发者都有相同的权限。

相反，SVN可以指定每个文件级别和每个目录级别的读和写权限控制，权限控制方面更加精细。

Git 仓库不能处理大型二进制文件。

SVN仓库除了可以处理代码外，还可以处理大型二进制文件。

在SVN中存储大型二进制文件会比在Git中占用更少的空间。

SVN不仅可以使用命令行，也可以作为一款客户端工具使用，不仅可以用于管理代码，还可以管理非代码类文件。

Git以命令行使用为主，而且，由于服务架构相对复杂，因此，使用方面有一定学习成本。

作为版本管理方面比较知名的两款工具，它们分别是集中式管理和分布式管理的代表，各有擅长的方向，很难下定结论哪个更好。

如果你要管理大型二进制文件或者非代码资产，SVN更具有优势。如果你对离线管理，或者对于分支和合并有更复杂的要求，那么可以选择Git。